home *** CD-ROM | disk | FTP | other *** search
- Path: druid.borland.com!usenet
- From: pete@borland.com (Pete Becker)
- Newsgroups: comp.lang.c
- Subject: Re: fast find algorithm
- Date: 11 Apr 1996 16:04:07 GMT
- Organization: Borland International
- Message-ID: <4kjahn$jp2@druid.borland.com>
- References: <Dp8wE6.8DG@cix.compulink.co.uk> <PdvZxMlyZE9U088yn@ime.usp.br> <4k9ggs$4ov@news1.mnsinc.com> <4kbrg8$luu@druid.borland.com> <316B2716.4993@airmail.net>
- NNTP-Posting-Host: pbecker.borland.com
- Mime-Version: 1.0
- Content-Type: Text/Plain; charset=ISO-8859-1
- X-Newsreader: WinVN 0.99.5
-
- In article <316B2716.4993@airmail.net>, markn@airmail.net says...
- >
- >Pete Becker wrote:
- >>
- >> If you use a linked list at each array location to resolve conflicts
- then
- >> you can delete elements.
- >
- >Knuth gives an algorithm for deleting elements from a table when using linear
- pr
- >obing,
- >and it's pretty easy to see how that would work. I'm not sure there is a
- practi
- >cal
- >way to remove elements when using a secondary hash probe...
-
- Good point: with linear probing you know where the next location is, and sooner
- or later you know that you're done. My guess is that deleting would be constant
- time in most cases, but O(n) worst case, where n is the size of the table.
-
-